¿Simplemente significa que tiene una funcionalidad integrada que proporciona la disposición para trabajar de forma asíncrona?

Sí, eso es básicamente lo que significa.

En un modelo "tradicional" de un subproceso por conexión ^* , acepta una conexión y luego transfiere el manejo de esa solicitud a un subproceso (ya sea uno recién iniciado o de un grupo, realmente no cambia mucho) y hacer todo el trabajo relacionado con esa conexión en ese hilo, incluido el envío de la respuesta.

Esto se puede hacer fácilmente con E/S síncrona/de bloqueo: tenga un método de read que simplemente devuelva los bytes de lectura y un método de write que bloquee hasta que finalice la escritura.

Sin embargo, esto significa que el subproceso que maneja esa solicitud no puede hacer nada más y también que necesita muchos subprocesos para poder manejar muchas conexiones/solicitudes simultáneas. Y dado que las operaciones de E/S toman un tiempo relativamente grande (cuando se mide en la velocidad de acceso a la memoria y computación), eso significa que la mayoría de estos subprocesos estarán esperando una operación de E/S u otra la mayor parte del tiempo.

Tener E/S asíncrona y una arquitectura central basada en eventos significa que cuando se inicia una operación de E/S, la CPU puede pasar inmediatamente a procesar cualquier acción que deba realizarse a continuación, que probablemente estará relacionada con una solicitud completamente diferente.

Por lo tanto, uno puede manejar muchas más solicitudes en un solo hilo.

Las "primitivas" solo significan que las operaciones básicas de E/S como "leer bytes" y "escribir bytes" hacia/desde conexiones de red o archivos se proporcionan como operaciones asíncronas y las operaciones de nivel superior deben construirse sobre ellas (nuevamente de forma asíncrona, para mantener los beneficios).

Como nodo lateral: muchos otros entornos de programación han tenido API de E/S asíncronas durante mucho tiempo o las han obtenido en los últimos años. Lo único que distingue a Node.js es que es la opción predeterminada : si está leyendo desde un socket o un archivo, hacerlo de forma asíncrona es lo que es "normal" y el bloqueo de llamadas es la gran excepción. Esto significa que todo el ecosistema que rodea a Node.js (es decir, casi todas las bibliotecas de terceros) funciona con esa suposición en mente y también está escrito de la misma manera.

Entonces, mientras que Java, por ejemplo, tiene E/S asíncrona, pierde esa ventaja tan pronto como usa cualquier biblioteca relacionada con E/S que solo admita el bloqueo de E/S.

^{* Uso conexión/solicitud indistintamente en esta respuesta, bajo el supuesto de que cada conexión contiene una sola solicitud. Esa suposición suele ser incorrecta en estos días (los protocolos más comunes permiten múltiples pares de solicitud/respuesta en una sola conexión), pero el manejo de múltiples solicitudes en una sola conexión no cambia fundamentalmente nada sobre esta respuesta.}

Significa que el nodo js no se detiene en las operaciones de entrada/salida. Supongamos que necesita hacer alguna tarea y tiene alguna condición de bloqueo, por ejemplo, si se presiona la tecla de espacio, haga esto o mientras no se presiona la tecla esc, siga tomando entradas ya que el nodo js tiene un solo subproceso, esto detendrá todas las operaciones y se centrará en hacer el trabajo de la condición de bloqueo hasta que finaliza es asincrónico permitirá que la aplicación no detenga otras tareas mientras realiza una, realizará otra tarea hasta que finalice la tarea y es por eso que usamos await para obtener valor de las promesas en la función asíncrona del nodo js cuando se procesan los datos luego, el puntero llegará a la línea donde está presente la línea de espera y obtendrá el valor o procesará la información a partir de ella.